4-1. 컨테이너를 다루는 도구, 도커(Docker) - 파트 1

4.1. 도커: 사실상 컨테이너 기술의 표준

4.1.1. 도커란 무엇인가

도커(Docker)는 컨테이너를 실행하거나 컨테이너 이미지를 만들고 배포하는 플랫폼임. 응용 프로그램을 실행 환경 단위로 패키지화하여 컨테이너 이미지를 생성하고, 이를 컨테이너 레지스트리를 통해 개발 환경에서 프로덕션 환경으로 균일하게 배포할 수 있음. 실행 환경 자체를 통째로 패키지화하기 때문에 어떤 환경에서든 동일한 방식으로 응용 프로그램을 동작시킬 수 있음.

용어 정리

도커 (Docker): 컨테이너 기반으로 애플리케이션을 빌드, 배포, 실행하기 위한 오픈소스 플랫폼
컨테이너 이미지 (Container Image): 애플리케이션을 실행하는 데 필요한 코드, 런타임, 시스템 도구, 라이브러리 등을 하나로 묶은 정적 템플릿
컨테이너 레지스트리 (Container Registry): 컨테이너 이미지를 보관하고 배포하는 저장소 (예: Docker Hub)

도커의 기본 워크플로우:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

 ┌──────────────┐     Build      ┌──────────────────┐
 │  Dockerfile  │ ─────────────→ │ 컨테이너 이미지    │
 └──────────────┘                │ (실행환경 패키지)  │
                                 └────────┬─────────┘
                                          │ Push / Pull
                                          ↓
                                 ┌──────────────────┐
                                 │컨테이너 레지스트리│ (Docker Hub 등)
                                 └────────┬─────────┘
                                          │
                        ┌─────────────────┼─────────────────┐
                        │ 배포 (Run)      │ 배포 (Run)      │ 배포 (Run)
                        ▼                 ▼                 ▼
                 ┌─────────────┐   ┌─────────────┐   ┌─────────────┐
                 │  개발 환경   │   │  테스트 환경 │   │  운영 환경   │
                 │ [컨테이너]  │   │ [컨테이너]  │   │ [컨테이너]  │
                 └─────────────┘   └─────────────┘   └─────────────┘
                  → 모든 환경에서 동일한 방식으로 작동 (높은 이식성)

도커는 다음과 같은 핵심적인 아키텍처적 장점과 철학을 기반으로 설계됨:

특징	설명
유연성 (Flexibility)	특정 프로그래밍 언어나 프레임워크에 종속되지 않고 환경을 구성할 수 있음
느슨한 결합도 (Loose Coupling)	시스템을 완전히 독립적인 구성 요소로 분해하고 이들을 조합하여 서비스 가능
경량 (Lightweight)	하드웨어 에뮬레이션과 게스트 OS가 없어 호스트의 컴퓨팅 자원을 매우 효율적으로 사용
확장성 (Scalability)	사용자의 트래픽 수요에 따라 컨테이너 인스턴스를 동적으로 쉽게 확장/축소 가능
휴대성 (Portability)	온프레미스, 가상 서버, 멀티 클라우드 간의 이동 및 마이그레이션이 매우 쉬움
보안 (Security)	컨테이너별 독립적인 격리 환경을 보장하여 시스템 안전성을 확보

4.1.2. 도커의 장점

도커를 도입하면 다음과 같은 운영/개발상의 강점을 얻을 수 있음:

신속한 실행: 컨테이너 구동 속도가 가상 서버보다 훨씬 빠름
안정적인 릴리스: 개발과 운영 환경이 완벽히 일치하여 배포 과정에서의 환경 오류를 원천 차단
손쉬운 배포와 확장: 이미지 단위로 배포가 이루어져 이식성과 확장성이 극대화됨

4.1.3. 도커 엔진이란

도커 엔진(Docker Engine)은 컨테이너 및 컨테이너 이미지를 직접 관리하고 관리 대상 객체들을 제어하는 응용 프로그램임. 클라이언트-서버(Client-Server) 아키텍처 형태를 띰.

도커 클라이언트 (Docker Client): 사용자가 명령어를 입력하는 사용자 인터페이스
도커 데몬 (Docker Daemon): 백그라운드에서 실행되며 실제 컨테이너와 이미지를 관리하고 클라이언트의 API 요청을 처리하는 서버 프로세스
도커 API (REST API): 클라이언트와 데몬 사이의 통신을 이어주는 표준 인터페이스. 도커 클라이언트는 도커 명령어를 실행할 때 데몬 API에 접속하게 됨

4.2. 도커가 주목받는 이유

4.2.1. 도커의 역사

도커의 등장과 성장 과정은 다음과 같음:

도커의 주요 역사 타임라인:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

   [2013년 3월]  ──→ 파이썬 콘퍼런스(PyCon)에서 도커 최초 발표
        │
   [2016년 6월]  ──→ 자체 컨테이너 오케스트레이션 기능인 '스웜 모드(Swarm Mode)' 추가
        │
   [2017년 10월] ──→ 사실상 표준이 된 '쿠버네티스(Kubernetes)'를 도커 엔터프라이즈에 통합

4.2.2. 도커의 주목도

구글 트렌드(Google Trends) 등 전 세계 개발 트렌드 분석 도구에서 'Docker' 키워드의 검색 추이를 보면 출시 이후 지속적으로 우상향 곡선을 그리며 성장하고 있음. 이는 도커가 일시적인 유행을 넘어 인프라 구성의 표준으로 완벽히 자리 잡았음을 방증함.

4.2.3. 도커가 폭발적으로 성장한 요인

도커가 업계 표준(De-facto Standard)이 된 가장 큰 원인은 개발자와 시스템 관리자 모두에게 훌륭한 사용자 경험(UX)을 제공했다는 점에 있음. 즉, 설치와 사용법이 극도로 간단함.

사용자 우선(User-First) 철학: 다른 복잡한 실행 환경 설정 과정을 걷어내고, 누구나 쉽게 실행 환경을 마이그레이션할 수 있는 직관적인 도구를 목표로 설계됨
이전 기술과의 차이: 도커 이전에도 리눅스 컨테이너(LXC) 등 컨테이너 기술 자체는 존재했으나, 사용법이 난해하여 대중화되지 못했음. 도커는 이를 패키징 개념과 단순한 명령어로 추상화하여 보급에 성공함
클라우드 보급 시기와의 적절한 매칭: 온프레미스에서 클라우드로 인프라를 이전하는 트렌드와 맞물려, 높은 이식성·가용성·확장성을 손쉽게 구현할 수 있는 도커가 필수 도구로 낙점됨

4.2.4. 컨테이너 기술의 발전을 지원하는 OCI

컨테이너의 포맷 및 런타임에 대한 파편화를 방지하고 업계 공동의 개방형 표준을 수립하기 위해 OCI (Open Container Initiative) 프로젝트가 시작됨.

발족: 2015년 6월, 도커(Docker)와 코어OS(CoreOS)를 포함한 컨테이너 업계 리딩 기업들이 주도하여 출범
표준 규격:
1. Runtime Specification (런타임 사양): 컨테이너 실행 환경과 프로세스 관리에 대한 규격
2. Image Format Specification (이미지 포맷 사양): 컨테이너 이미지를 빌드하고 구성하는 아카이브 파일 구조에 대한 규격
의의: OCI 표준 제정을 통해 벤더에 종속되지 않는 에코시스템이 구축되었으며, 이는 컨테이너 기술이 비약적으로 발전하는 기폭제가 됨

4.3. 도커 컨테이너: 외부의 영향을 받지 않는 독립된 환경

4.3.1. 컨테이너란

컨테이너는 운영체제 위에서 실행되는 독립적이고 격리된 프로세스임.

일반적인 프로세스는 호스트 OS 내의 다른 프로세스들과 자원 및 환경을 직접 공유하지만, 컨테이너 프로세스는 커널의 네임스페이스(Namespace) 기술을 통해 격리됨. 네임스페이스를 활용하면 프로세스 ID(PID), 네트워크 인터페이스, 마운트 지점 등을 다른 영역과 완벽히 구분하므로, 외부 환경의 간섭을 받지 않는 독립된 가동 영역을 갖게 됨.

4.3.2. 파일 시스템의 격리

격리 메커니즘에서 가장 중요한 핵심은 파일 시스템의 격리임.

일반 프로세스: 호스트 OS의 파일 시스템을 그대로 공유하며 사용함
컨테이너 프로세스: 컨테이너 내부에 독립적인 전용 파일 시스템을 마운트하여 사용함

이러한 특성은 특히 패키지 의존성 문제를 해결할 때 탁월한 강점을 가짐. 예를 들어 하나의 운영체제 내에서 버전이 서로 다른 패키지(예: 다른 버전의 Python, Node.js 라이브러리 등)를 동시에 설치하는 것은 호환성 문제를 유발하기 쉬움. 하지만 컨테이너는 독립된 파일 시스템을 가지므로 호스트 OS나 다른 컨테이너에 영향을 주지 않고 서로 다른 버전의 패키지를 완벽히 공존시킬 수 있음.

4.3.3. 컨테이너와 가상 서버의 차이

가상 서버(Virtual Machine)는 호스트 OS형 가상화나 하이퍼바이저형 가상화 위에서 작동하는 가상 하드웨어 세트와 게스트 OS를 의미함.

도커 등장 초기에는 가상 서버와 컨테이너를 혼동하여, 컨테이너 내부에 monit 같은 프로세스 감시 도구를 올리거나 SSH 데몬을 실행해 직접 접속하는 등 컨테이너를 가상의 컴퓨터처럼 무겁게 쓰는 잘못된 사례가 많았음.

격리 수준 비교 (컨테이너 vs 가상 서버):
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

[컨테이너 방식: 프로세스 격리]
┌───────────────────────────────┐
│  컨테이너 A   │   컨테이너 B  │
│ (독립 프로세스)│ (독립 프로세스)│  ← 네임스페이스로 격리
├───────────────────────────────┤
│          도커 엔진            │
├───────────────────────────────┤
│         호스트 OS             │  ← 운영체제(커널) 공유
├───────────────────────────────┤
│          하드웨어             │
└───────────────────────────────┘

[가상 서버 방식: 하드웨어 에뮬레이션]
┌───────────────┬───────────────┐
│   가상 서버 A  │   가상 서버 B  │
│  ┌─────────┐  │  ┌─────────┐  │
│  │   앱    │  │  │   앱    │  │
│  ├─────────┤  │  ├─────────┤  │
│  │게스트 OS│  │  │게스트 OS│  │  ← 각각 독립된 OS 탑재
│  └─────────┘  │  └─────────┘  │
├───────────────────────────────┤
│        가상화 소프트웨어       │  ← 하드웨어 에뮬레이션
├───────────────────────────────┤
│         호스트 OS             │
├───────────────────────────────┤
│          하드웨어             │
└───────────────────────────────┘

컨테이너 vs 가상 서버 핵심 비교

구분	컨테이너 (Container)	가상 서버 (Virtual Machine)
본질	격리된 프로세스	하드웨어를 모방한 가상 하드웨어 + 게스트 OS
운영체제 공유	호스트 OS(정확히는 커널)를 공유	독립적인 게스트 OS를 각각 탑재 (공유 안 함)
격리 방식	네임스페이스(Namespace), cgroups 등	하이퍼바이저를 통한 하드웨어 수준 격리
기동 속도	프로세스 실행 수준으로 매우 빠름 (밀리초 단위)	게스트 OS 부팅이 필요하여 상대적으로 느림 (초~분 단위)
리소스 사용량	오버헤드가 거의 없어 매우 경량	게스트 OS 구동을 위한 리소스 오버헤드가 큼

요약

컨테이너를 가상 서버와 같은 미니 컴퓨터로 보기보다는, 커널 기술로 보호받는 특수한 프로세스로 인식하는 것이 올바른 이해 방법임.

4.3.4. 어떻게 컨테이너에 운영 체제를 탑재할 수 있을까?

컨테이너 환경에서 Ubuntu, CentOS 등 다양한 운영체제를 올릴 수 있는 이유는 리눅스의 배포판(Distribution) 개념 때문임.

리눅스 배포판: 하드웨어를 제어하는 핵심인 리눅스 커널에 각 배포판 고유의 사용자 공간 소프트웨어 세트를 결합한 것
원리: 컨테이너는 호스트의 리눅스 커널을 공유하되, 컨테이너 내부에 Ubuntu나 CentOS의 소프트웨어 세트(패키지 관리도구, 기본 라이브러리 등)를 포함하여 배포함. 따라서 컨테이너 내에서 실행되는 프로세스는 마치 실제 우분투나 센토스 환경 위에서 작동하는 것처럼 느끼게 됨

이러한 배포판 분리 방식을 통해 무거운 게스트 OS를 직접 실행하지 않고도 하나의 물리 시스템 내에 여러 배포판 환경을 공존시킬 수 있음.

4.3.5. 컨테이너가 있다면 가상 서버는 필요 없을까?

가볍고 빠른 컨테이너가 가상 서버의 상위 호환처럼 보일 수 있지만, 가상 서버 역시 반드시 필요한 핵심 기술임:

운영체제 커널의 호환성 제약: 컨테이너는 호스트 OS의 커널을 공유하므로, 호스트 OS 커널과 컨테이너 내부 소프트웨어의 커널 버전 차이 및 아키텍처 호환성 문제로 정상 작동하지 않는 경우가 존재함
가상 서버의 이점: 가상 서버는 커널을 포함하여 완전히 독립적인 독립 OS 환경 전체를 제공하므로 호스트 OS와의 호환성 제약에서 완전히 자유로우며, 이기종 OS(예: Linux 호스트 위에서 Windows 실행) 개발 환경을 구축할 때는 가상 서버를 사용하는 것이 필수적임

4.4. 컨테이너 이미지: 컨테이너를 실행하기 위한 템플릿

4.4.1. 컨테이너 이미지란

컨테이너 이미지는 컨테이너라는 가동 환경을 생성하기 위한 템플릿이자 설계도임. 객체 지향 프로그래밍(OOP)에서의 클래스(Class)와 객체(Object) 관계에 비유할 수 있음.

클래스 (Class) = 컨테이너 이미지: 속성과 메서드를 정의하지만, 그 자체가 실행되지는 않음
객체 (Object) = 컨테이너: 클래스를 기반으로 실체화되어 실제로 동작하고 상태를 가짐

컨테이너 이미지의 실체는 애플리케이션 실행에 필요한 파일들을 계층 구조로 쌓아 올린 독립 파일 시스템임. 이 파일 시스템 레이어(Layer)들은 도커의 차분 관리(Copy-on-Write) 방식을 통해 효율적으로 관리되며, 그 외에도 시작 프로세스 명령, 환경 변수 등 실행을 위한 설정 정보가 포함되어 있음.

4.4.2. 컨테이너 이미지의 생성

컨테이너 이미지는 기본(Base) 이미지 파일 시스템 위에 새로운 레이어를 지속적으로 누적하여 생성함:

이미지 레이어 적층 예시:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

 ┌───────────────────────────────────────┐
 │   새 레이어: 구성 파일 + 아파치 설정  │
 ├───────────────────────────────────────┤
 │   새 레이어: 아파치(Apache) 웹 서버   │
 ├───────────────────────────────────────┤
 │   베이스 이미지: CentOS 파일 시스템   │
 └───────────────────────────────────────┘
  → 레이어들이 하나씩 쌓여 최종 아파치 웹 서버 이미지가 완성됨

컨테이너 내부에서 직접 명령어를 입력해 변경 사항을 수동으로 빌드할 수도 있지만, 대개는 이미지 생성 과정을 텍스트 문서로 정의한 **도커파일(Dockerfile)을 사용해 자동으로 빌드함.

4.4.3. 컨테이너 이미지의 배포

실행 중인 프로세스인 컨테이너 자체는 네트워크로 전송할 수 없지만, 파일 데이터 구조인 컨테이너 이미지는 데이터 형태로 손쉽게 배포할 수 있음.
배포된 컨테이너 이미지를 다운로드받아 구동하면 전 세계 어느 환경에서든 완벽하게 동일한 실행 상태를 재현할 수 있으며, 이 성질을 도커의 **이식성(Portability)이라고 함.

4.4.4. 컨테이너 이미지는 운영체제 설치 디스크와 같은 것일까?

특정 배포판의 이름을 달고 유포된다는 점에서 OS 설치 디스크(ISO 등)와 비슷해 보이지만 명확한 차이점이 존재함:

구분	컨테이너 이미지	OS 설치 디스크 (ISO 등)
커널 포함 여부	리눅스 커널을 포함하지 않음 (호스트 커널 공유)	자체 부팅을 위한 리눅스 커널을 포함함
작동 원리	프로세스가 이미지 내부 소프트웨어에 직접 접근 (복사 없음)	소프트웨어를 하드 디스크 드라이브 등으로 복사하여 설치
격리 환경	독립된 파일 시스템 레이어를 사용해 격리 구현	독립된 하드웨어 영역에 가상 OS 환경 구축

4.5. 컨테이너의 라이프 사이클: 컨테이너 생성에서 삭제까지

4.5.1. 라이프 사이클이란

컨테이너는 생성에서 소멸까지 몇 가지 고유한 상태와 상태 변화 흐름을 지님.

도커 컨테이너 라이프 사이클:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

          docker container create
                     │
                     ▼
              ┌─────────────┐
              │ 생성 상태    │ (Created)
              └──────┬──────┘
                     │ docker container start
                     ▼
   ┌───────────────────────────────────┐
   │          실행 상태 (Running)      │ ◀──┐
   └──────┬──────────┬───────────▲─────┘    │
          │          │           │          │
          │docker    │docker     │docker    │docker
          │stop      │pause      │unpause   │restart
          ▼          ▼           │          │
    ┌──────────┐  ┌──────────────┴─┐        │
    │ 정지 상태 │  │ 일시정지 상태    │        │
    │ (Stopped)│  │   (Paused)     │        │
    └─────┬────┘  └────────────────┘        │
          │                                 │
          │       정지 중 프로세스 종료        │
          └─────────────────────────────────┘
                     │
                     ▼ docker container rm
              ┌─────────────┐
              │ 삭제 상태    │ (Deleted)
              └─────────────┘

도커 환경에서 가질 수 있는 컨테이너 상태는 크게 5가지임:

생성 (Created): 컨테이너 격리 구조와 레이어는 만들어졌으나 아직 내부 프로세스가 실행되지 않은 상태
실행 (Running): 컨테이너 내부의 진입 프로세스가 활성화되어 동작 중인 상태
정지 (Stopped): 내부 프로세스가 정상 종료되거나 외부 중지 명령을 받아 실행이 끝난 상태 (디스크 자원은 보존됨)
일시 정지 (Paused): 컨테이너 프로세스를 메모리 상에서 동결(Freeze)해 가동을 멈춘 상태 (CPU 사용 중단, 메모리 상태는 보존)
삭제 (Deleted): 컨테이너의 격리 구조 및 디스크 레이어 데이터가 완전히 삭제된 상태

정지(Stopped) vs 일시 정지(Paused) 상태 비교

구분	정지 상태 (Stopped)	일시 정지 상태 (Paused)
프로세스 상태	프로세스가 완전히 종료됨	프로세스가 동결(Freeze)됨
메모리 유지	메모리 상의 데이터가 사라짐	메모리 상의 기록과 상태가 그대로 유지됨
다시 시작 시	프로세스가 처음부터 초기화되어 시작	일시 정지되었던 시점부터 프로세스가 즉시 재개

4.5.2. 컨테이너의 상태 변화

컨테이너 상태는 도커 명령을 실행하거나 내부 프로세스가 자연 종료될 때 변경됨:

docker container run 명령을 내리면 컨테이너 디스크 레이어가 즉시 생성(Created)되고 바로 내부 프로세스가 기동되어 실행(Running) 상태로 변경됨
실행 중 프로세스가 임무를 완수하고 스스로 종료되면 컨테이너의 상태는 자동으로 정지(Stopped)로 전환됨

4.6. 도커 데몬

4.6.1. 도커 엔진을 구성하는 세 구성 요소

도커 엔진은 기능이 독립된 세 가지 구성 요소로 이루어져 있음:

도커 엔진 구성 요소와 역할:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

 ┌────────────────────────────────────────────────────────┐
 │                   [ 도커 클라이언트 ]                    │
 │ - 도커 데몬의 사용자 인터페이스 역할                       │
 └──────────────────────────┬─────────────────────────────┘
                            │ REST API 통신
                            ▼
 ┌────────────────────────────────────────────────────────┐
 │                     [ 도커 데몬 ]                       │
 │ - 이미지, 컨테이너, 네트워크 등 도커 객체 실질 관리          │
 └──────────────────────────┬─────────────────────────────┘
                            │ 이미지 업로드/다운로드
                            ▼
 ┌────────────────────────────────────────────────────────┐
 │                 [ 컨테이너 레지스트리 ]                   │
 │ - 도커 이미지를 영구 보존하고 배포하는 클라우드 저장소        │
 └────────────────────────────────────────────────────────┘

도커 클라이언트 (Docker Client): CLI 명령줄 창을 통해 사용자와 상호작용하는 대화용 컴포넌트
도커 데몬 (Docker Daemon): 실질적인 서버 백그라운드 프로세스로서 클라이언트의 요구에 맞게 도커 객체(Object)를 컨트롤함
컨테이너 레지스트리 (Container Registry): 공유 서버 저장소로, 대표적으로 공용 저장소인 도커 허브(Docker Hub)가 있으며 기업 내부용 프라이빗 레지스트리를 구축할 수도 있음

4.6.2. 도커 객체란 무엇인가

도커 객체(Docker Object)는 도커 데몬이 생성하고 제어하는 관리 대상 데이터 모델을 뜻함.

이미지 및 컨테이너: 가장 대표적인 관리 객체
네트워크 (Network): 컨테이너 간의 통신과 외부 연결을 수행
볼륨 (Volume): 컨테이너 삭제 후에도 데이터를 영구적으로 유지하기 위한 스토리지 인프라

4.6.3. 도커 데몬과의 통신 방법

도커 클라이언트와 도커 데몬은 HTTP 기반의 REST API를 사용하여 통신함.
도커 데몬은 일종의 백그라운드 웹 서버 구조로 돌아가기 때문에, RESTful API 요청을 정상적으로 보내고 응답을 받을 수 있는 프로그램이라면 도커 클라이언트가 아니더라도 도커 데몬에 명령을 보낼 수 있음. (특정 기본 데몬 리포팅 기능 등은 브라우저를 통해 포트에 다이렉트로 접속하여 확인할 수도 있음)

4.6.4. 컴포넌트가 격리·구분되어 있을 때의 장점

도커 클라이언트와 도커 데몬이 논리적으로 철저히 구분되어 있는 아키텍처는 다음과 같은 이점을 제공함:

유연한 원격 실행: 클라이언트와 데몬이 서로 물리적으로 다른 시스템에 배치되어 원격으로 컨테이너 제어 가능
UI 유연성: CLI 환경의 명령줄 클라이언트뿐 아니라 GUI 형태의 통합 관리 프로그램(예: Docker Desktop)으로 손쉽게 클라이언트를 교체하고 확장할 수 있음
디버깅 편리성: 도커 엔진 오동작 시 클라이언트와 데몬 사이의 HTTP REST API 네트워크 전송 메시지를 직접 캡처 및 모니터링하여 오류 원인을 면밀히 분석 가능

핵심 요약

4-1장. 도커 개요 및 핵심 개념 요약:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

[도커(Docker)]
└─ 컨테이너 이미지 빌드·배포·실행을 돕는 업계 표준 플랫폼
   ├─ 강점: 유연성, 느슨한 결합, 경량성, 확장성, 이식성, 보안
   └─ 구성: 클라이언트(CLI), 데몬(서버), 레지스트리(저장소)

[OCI (Open Container Initiative)]
└─ 컨테이너 실행 규격(Runtime Spec)과 포맷(Image Spec)의 업계 공통 표준

[컨테이너 격리 특징]
├─ 본질: 호스트 커널을 공유하는 독립적 격리 프로세스
├─ 기술: 네임스페이스(Namespace) 기반의 네트워크 및 PID 격리
└─ 파일 시스템: 독립된 전용 레이어를 마운트하여 패키지 버전 간섭 해결

[컨테이너 vs 가상 서버]
├─ 컨테이너: OS 커널 공유 · 기동 빠름 · 경량
└─ 가상 서버: 독립된 게스트 OS 각각 탑재 · 무거움 · 완벽한 독립 커널 제공

[컨테이너 이미지]
├─ 컨테이너 인스턴스를 찍어내는 정적 템플릿 (클래스-객체 관계)
└─ 특징: Copy-on-Write 차분 레이어 구조 · 리눅스 커널은 포함하지 않음

[라이프 사이클]
├─ 상태 흐름: 생성 → 실행 ⇄ (정지 / 일시 정지) → 삭제
└─ 일시 정지(Paused): 프로세스를 동결하여 메모리 및 CPU 현재 상태를 보존

참고 자료

관련 자료:

Docker 공식 아키텍처 가이드: https://docs.docker.com/get-started/overview/
OCI (Open Container Initiative) 공식 웹사이트: https://opencontainers.org/
Docker Hub 공식 이미지 레지스트리: https://hub.docker.com/
Linux namespaces(네임스페이스) 매뉴얼: https://man7.org/linux/man-pages/man7/namespaces.7.html

네비게이션

이전 강	목록	다음 강
◀ 3. 컨테이너 기술과 기초 지식	목록으로	4-2. 컨테이너를 다루는 도구, 도커(Docker) - 파트 2 ▶